Methods of the type in question are nowadays widely used for the transmission of speech, audio, video and/or useful data across network boundaries, e.g. between internal and public data networks. During the transmission of data over IP networks, problems repeatedly arise when an address translation is performed at a network boundary using NAT (Network Address Translation). For various reasons, NAT is of crucial importance for Internet technology here. In addition to providing load distribution in parallel processing, various types of access security provisions in the sense of a firewall as well as fault tolerance and high availability are supported. Basic network administration functions are also simplified.
Since the address space provided at the time the Internet was founded will no longer suffice for the assignment of IP (IP: Internet Protocol) addresses in the foreseeable future, and especially since the expansion of internal and highly complex data networks requires more and more IP addresses, NAT is however used above all to hide internally used IP addresses from the outside. Firstly this makes it easier to manage internal networks, and secondly it saves on costs, since fewer chargeable public IP addresses need be used externally than are actually required internally. In principle it is theoretically possible here to map an internal network of up to 60,000 computers to a single public IP address by varying the port address of the public IP address.
With NAT, when an IP data packet is sent, first of all the IP header of this packet is exchanged. The internal IP address including port number is replaced by a public IP address with a different port number. An NAT host stores the mapping of internal IP address to the public (external) IP address. If the NAT host then receives an IP data packet, it maps the public (external) IP address back onto the internal IP address. The NAT host should be understood here as a computer linking two networks together on which appropriate software (NAT engine) handles the address translation.
It is however a problem that some IP protocols also send the internal IP addresses again as protocol data (e.g. with Voice-over-IP protocols). At the NAT host only the IP headers of a data packet are exchanged, the protocol data itself is not accessed, since it cannot be resolved by the NAT host. The addressed external computer in the public network now sends its reply, not to the public address in the IP header of the data packet, but to the internal IP address which the service used (e.g. Voice-over-IP) has read out from the protocol data. However, the original sender cannot be reached under this address. The reply is therefore sent either to an unknown IP address or to a different public computer which is unable to do anything with this IP data packet.
The problem described here has hitherto not been solved. There have been isolated attempts to use directly on the NAT host a protocol analyzer which is able to unpack certain protocols and also, in addition to the IP header, to change here the protocol data in accordance with the NAT mapping. However, this regular access to protocol data together with its analysis would slow down the data traffic considerably. Moreover, depending on the protocol type used, it might prove necessary to use not just one, but several protocol analyzers. The problem could be solved in future by IPv6 (Internet Protocol Version 6—with extended IP address space), but IPv6 will not be implemented across the board for a long time to come. Owing to the greatly increased interest of companies in Internet telephony and in exchanging image and useful data, however, a speedy and reliable solution of the problem outlined is required.